The generic adk_request_credential consent round-trip existed, but nothing
triggered it for MCP: mcptoolset applies auth in the transport's RoundTripper,
which cannot start a consent flow (it has no function call id), and the MCP SDK
drops the underlying error chain — so a provider's auth.ConsentRequiredError
never reached the tool through CallTool. Interactive (3-legged) OAuth for MCP
tools therefore could not work.

This wires the interactive path for MCP:

- mcptoolset passes Config.Auth to each tool and, before calling the server,
  probes the provider. If it returns auth.ConsentRequiredError, the tool calls
  ctx.RequestCredential (pausing the run for consent) and returns the new
  tool.ErrCredentialRequired sentinel. On success the provider caches the
  credential, so the RoundTripper reuses it on the actual call — no extra network
  round-trip for the common (GCP) case.
- A non-consent resolution error fails fast with the real cause (the RoundTripper
  would fail the same way on the call below, but the MCP SDK would mangle the
  error chain).
- ctx.AuthResponse guards the resume: once the user has consented, a provider
  that still cannot mint a credential fails instead of looping.
- tool.ErrCredentialRequired is the credential analog of ErrConfirmationRequired;
  retryandreflect skips it like the other HITL sentinels.
- Config.Auth documents that interactive consent is driven only during tool
  execution; tool listing (Tools) cannot pause, so a server that authenticates
  listing needs a non-interactive or already-consented credential.

Testing: go build ./..., go test -race -shuffle=on ./..., golangci-lint run,
go mod tidy -diff — all green. New tests cover the consent request,
proceed-after-consent, the no-loop guard, fail-fast on a non-consent error, and
the no-provider path.